Like “(FindWindow (), whichWindow);” having no ampersand (&) before “whichWindow”. That one will cause a crash - not just a debugger error, when you get past compile and link.
Speaking of ampersands... Toolbox calls requiring the “address of” operator (ampersand, or ‘&’), like SetRect and lots of other QuickDraw calls, are best handled (as I’ve said) for the whole file when the first one is encountered. CTools™ only takes care of converting the ‘@’ which was already in the Pascal program. Almost ALL Pascal I’ve seen has no spaces before the first paren of a call. This is to your advantage in the translation process. Suppose you’re doing “SetRect” missing ampersands...
You want “Whole Words” checked so you don’t mess up “OffsetRect”. But you also want “Ignore Case” checked in case there are instances or “setrect” or “SETrect” or some such. Fix all that can be fixed with each correction you do.
Find “SetRect(“ and replace with “SetRect (&”. See? We added a space before the paren. Why? Well, if you do Replace All, it won’t matter. But if you replace one at a time (Replace, Find Again) you have to be careful not to go past where you started, thus creating more editing to handle the over correction. It will find “SetRect(&” and fix it with “SetRect(&&”. See? With the space after the paren it won’t redo one already done.
So I always add the space between the call and its paren, especially when using Command G/H. Besides, it’s proper punctuation in English!
(The “CopyBits” and “CopyMask” will drive you crazy if you translate Stella Obscura by John Calhoun! CopyBits needs 4 ampersands. As I recall, there were 90 CopyBits calls in Stella Obscura - probably 45 CopyMask calls! I can probably set up some built in macros to handle some of these.)
In my KodeKeys macros, I use the single ‘.’ key on the numeric keypad section of the keyboard to type an ampersand. That way I don’t have to use the shift key. One hand on the mouse and one finger on the other hand on that key and I can knock these things in like nobody’s business.
